shouldn't this be behind a check which version of java we're on?

see discussion here: #326

Well, we would need to decide how.

Either we put a dependency to the puppetlabs-java module and use its facts. However this adds a whole module to be aware of, just for that "little" fact. Many users use it to install the needed Javas (like we do), but not all i would guess.

Another option would be a custom fact to this module which should have a special name like "...jira_java..." or so to not conflict with the facts of puppetlabs-java (for the people who use that module to install the needed java). Code could be copied from puppetlabs-java. This could also have the advantage of checking the java with the user, which will actually run Jira.

Or we leave it completely up to configuration with a required variable somewhat like discussed in #326 , forcing the user to set it, but that is no smart way in my opinion.

Any opinions/favourites?

can we try use the facts without depending on it?

we'd have to do it defensively, but so does every module which relies on facts that are only available after the software has been installed, i.e.: after it was run, so it's not like we'd be breaking new ground here

@igalic I dont get you completely. You mean to use the facts from puppetlabs-java, but without setting the dependencies in metadata.json? That is not smart in my opinion, because then we would need to tell in the documentation, that for proper JVM_GC_ARGS variables one needs to install puppetlabs-java.

There is another thing: #326 was created, because Java 11 does not like "PrintGCTimeStamps", however "PrintGCTimeStamps" is not in the upstream code anymore for Jira 8.7.1. If we want to be downwards-compatible with older Jira version, we have a problem. Alternative could be that we say, the new release of the module is only compatible with Jira 8.7.1 and newer. Or we remove the "PrintGCTimeStamps" also for older Jira releases.

Also java version check is not enough, for java 11 we might need to compare the value of jira::jvm_xmx also.

My proposals would be the following:

• introduce a custom fact for the java version in this module (no dependencies required then)
• make parameter similar to Make JVM_EXTRA_ARGS manageable for java 11 compatibility #326, but default value is empty
• if previous mentioned parameter is empty, set value depending on custom fact and jira::jvm_xmx value. If not empty use the value of the parameter
• set "PrintGCTimeStamps" only for Jira Versions < 8 or alternatively check setenv.sh of every jira release from 7.x until 8.7 to see, when they really removed it

I would also put the following in consideration: which Jira versions are still supported and which Java versions are supported by these versions? Write this in the documentation. Going for the smallest commonality. I am fine with depending on puppetlabs-java and would write documentation for it.

Jira 7.12 to 8.12 is supported, 7.12 only has support for OracleJava 8, 7.13 to 8.1 have support for Oracle & OpenJDK8. 8.2 Onwards has Java11 support.

Here are the EOL Dates:
8.1 (EOL Date: Apr 4, 2021)
8.0 (EOL Date: Feb 11, 2021)
7.13 (EOL Date: Nov 28, 2020)
7.12 (EOL Date: Aug 27, 2020)

Since 7.12 just dropped out of support, it's much easier to maintain, because openJDK/JRE is always available

@timdeluxe, @SimonHoenscheid In #326 I've added the 'jvm_type' parameter, which can be set to the used JVM version, which is used in setenv.sh and other configurations.

The current changes in #326 tackle the following aspects of your comment:

introduce a custom fact for the java version in this module (no dependencies required then)
make parameter similar to #326, but default value is empty

As you asked, I've set the default to 'oracle-jdk-1.8' and left the default parameters for jvm_optional, jvm_extra_args, jvm_gc_args, jvm_codecache_args empty. If someone chooses to use JDK 11, the jvm type can be set to openjdk-11 or even to custom if parameters don't line up.

I wonder if we would need to add something like "jvm_gc_args_additional" variables, so that someone who chooses a 'jvm type != custom' does not need to fallback to custom if one parameter needs to be adjusted. I've put that one into my PR #326 as well, including a test. Another option would be, that we add the 'jvm_*' args if they are not empty and the jvm_type points to something default like 'oracle-jdk-1.8'. What do you think?

if previous mentioned parameter is empty, set value depending on custom fact and jira::jvm_xmx value. If not empty use the value of the parameter

I think, leaving the jvm_type parameter empty is too much implicit behavior. If someone wants custom parameters to be set the behavior should be explicitly defined.

set "PrintGCTimeStamps" only for Jira Versions < 8 or alternatively check setenv.sh of every jira release from 7.x until 8.7 to see, when they really removed it

The PrintGCTimeStamps is a java parameter, it shouldn't be judged by the jira version.